CV3 hack progress log. 

NOTE: Production officially began in January 2008, but work 
was postponed for six months until July to finish work on my 
B.A. in geography. In January, I began developing the doors 
that take the player between areas as well as the routine 
that allows the player to move between different sections of
areas by simply walking to the edge of the screen. I also 
made many documentations on the scroll coding for the game's 
vertical scrolling areas.

07/02/08- "boss gone" condition slipped into "$2A #01" routine. Failure.
07/03/08- Exact condition for a boss's appearance has been found at 0x28F01. 
          A dummy "boss gone" condition sub routine has been implemented at 
          0x29910, a location used for items in a certain place late in the 
          game. It has proven to be successful for the most part.
07/07/08- Minor glitch with "boss gone" corrected. I have also nullified the
          timer. Music now resumes after boss is killed. New routine for this 
          and the glitch correction implemented at 0x3F5F.
07/08/08- Game handed over to Dr. Mario for graphical experimentation. Routine 
          created for making sure that progress is kept after dying implemented 
          at 0x3BFB0, during which a player dies, and for when a player returns
          to life, at 0x3F4B1. $2D is used as temporary storage for $46F. I 
          eliminated a glitch involving graphics scrambling during a room change 
          via staircases.
07/14/08- Two tables storing attributes of where a player appears during an event 
          of a stage change or reappearance after death have been merged into one 
          table. I don't to bother discussing details because it would take too 
          too long. The table has also been reconfigured to store XY map 
          coordinates for the games soon to exist map screen for these events. The 
          table itself hasn't been completedly remade yet, but appears that it will 
          fit. The routine for this table (actually, 3 tables depending on where 
          the player is coming from) starts at 0x13364. This table merging will 
          allow for some more free space, much of which will be used to help store 
          the XY map screen coordinates. These coordinates are currently stored 
          at the ram addresses previously used for storing the number of seconds 
          in the timer.
07/16/08- A full functioning room that appears between two levels when the 
          player goes through a door has been successfully implemented. This 
          was procedure was carefully planned on paper and successfully executed. 
          So far, there is space for five more of these special rooms. These 
          special rooms will replace the level block in the dancing hall, the one 
          where floor would collapse under the player leading up to the Grim Reaper. 
          A long stretch of rooms in a short level was needed and this was by far 
          the best candidate. Much space was eaten up in this procedure, particularly 
          toward the end of the rom's first bank (3FXX region). But it's 
          definitely for the best.
07/20/08- Did a lot of "little things" today. I eliminated the hearts/time drain 
          routine that occurs after collecting the "ball" after defeating a boss 
          by editing some pointers in a table at 0x4007. I also made sure that the 
          player could perform operations that involve pushing the start and select 
          buttons after defeating a boss by taking out a few subroutines at 0x23F36, 
          when after the ball is collected, and at 0x248BB, for when before the 
          ball is collected. The amount of health and hearts are now retained when 
          the player enters a new area, editing two JSRs at 0x10F9 and 0x11FE. 
          The graphical sloppiness of the room changes was virtually eliminated by 
          creating some appropriate subroutines within the $2A=#13 routine.
07/21/08- A glitch when the player disappears before he hits the ground after a 
          room change was fixed by storing the value of the players graphics ($400) 
          into another ram address temporarily ($A9) until the players graphics 
          are restored. When restored, $A9 is set back to #00. This may cause some 
          glitches in the future, but for now it will have to do.
07/22/08- More convenient starting positions after death made possible by adding 
          content to the starting routines. Temporarily uses ram location $2E.
07/28/08- A glitch was fixed for the door routines. $D2 is temporarily used to 
          repair it.
08/07/08- Construction has begun on the portal rooms. The portals themselves can 
          now be entered by pressing up while the player is in front of them. They 
          don't really lead anywhere yet-- they just make the player reappear in 
          the same room for now. A JSR has been slipped into location 0x39BB6, which 
          makes a staircase a portal if the current level=0C.
08/21/08- CV2 theme "Bloody Tears" sequenced using CV3 music engine and currently 
          plays for the first level of the game. It sounds remarkably similar to 
          the version in Simon's Quest, but not quite as impressive. It will likely 
          be used for the clock tower stage as it was in Super Castlevania.
08/22/08- Theme "Celestial" sequenced. Slated to be used for the celestial garden.
08/23/08- I have started making the game more aesthetically tolerable in terms of 
          level design and placement of graphics using Revamp. Dr. Mario has inserted 
          the graphics into the game and shipped it back to me.
08/25/08- Theme "Bloodlines" sequenced for the game's initial stage. Also, 
          percussion has been added to "Celestial"
09/12/08- Another original track sequenced.
09/28/08- The portals function fully and take the players where they are supposed to. 
          Ram locations $DC and $DD are used temporarily to aid this. A table routine 
          has been implemented at 0x33E86 that define where each portal will take the 
          player. Music for these rooms has been turned off by silencing the track 
          "Destiny".
09/29/08- A temporary solution has been given for the vertical scrolling areas in the 
          game. when the player enters a vertical area from above, the screen scrolls 
          down, and when entering from below, it scrolls up. A JSR pointing to new 
          custom code has been implemented at 0x3D0?? to make this possible. 
11/17/08- After a long time,"Hysteria" is finally sequenced. This song is something of 
          a breaktrough, moving from the casual to the epic, and still generates the 
          feel of a classic NES game.
01/03/09- Construction has begun on a menu screen that will be used during normal game 
          play. Ideally, it will have a real time map and a character selection 
          interface. So far, only the background of the map appears when the player 
          presses select during normal gameplay, but many elements of the games original 
          map screen that occured between levels (which will be used to create this 
          menu screen) have been deconstructed and identified.
01/06/09- A method to return to normal gameplay from the map screen has been found. A 
          loop needs to be created for the player to remain in the map screen until a 
          button is pushed once again (select). While in this loop, the player should 
          be able to push other buttons to select things from menus.
01/09/09- Made some features return to normal once the player exits the map screen.
01/10/09- Some more features returned. Slowly but surely coming along.
01/11/09- A phenomenally simple solution to exiting the map screen appears to has 
          been found. A JSR embedded in the $2A, #02 has the distinction of loading 
          sprites of enemies and items on the screen. All I have to do is provide a 
          condition to bypass this JSR when the map screen exits, then load $2A with 
          #01. If this hold, and I'm confident it will, much space will be saved. 
          This had me stumped for days and it is a massive relief to have finally 
          solved it using the best way possible. In the process of doing this, I 
          have learned a huge deal more on both 6502 and the Castlevania 3 engine.
01/12/09- Minor touch ups involving the map screen. I've noticed that there is much 
          still to be done for this routine to work properly as I've documented more 
          stuff that doesn't quite work with it, including it not working in the 
          vertical areas or during boss fights properly.
01/13/09- Sprites from normal gameplay no longer appear in the map screen. A minor 
          glitch occurs as a result of this routine, but there should be a way to 
          repair it, as there always is pretty much.
01/15/09- An attempt was made to construct the HUD. When it was organized graphically 
          according to plan, the game began breaking up slightly. It was eventually 
          discovered that the glitching was a result of too much ram being used up in 
          page $300 of ram. In other words, the new HUD has more graphical tiles than 
          can be safely used... After reducing many of the tiles and routines that 
          originally utilize the HUD, however, much of this ram space has been saved. 
          But there is still more to be incorporated into the HUD. Now it's just a 
          question of whether or not the saved ram space can be used properly. All 
          four characters have access to the map screen now.
01/16/09- The enemy power bar in the new HUD was given new graphics for when it is 
          drained. Both power bars have been extended. New default values were given 
          for the energy bars throughout the rom (full power is now #68 instead of 
          #40). Name of part of the castle as well as new double/triple shot indicator 
          also added to the HUD. It's effectively complete. A fair amount of rom has 
          been freed up in the 0xD00-EFF region.
01/21/09- I've become painfully close to allowing the map screen to exit properly in 
          the vertical scrolling areas. It has one nagging shortcoming in which a 
          bottom potion of the screen loads the incorrect bg graphics. Made a dummy 
          routine within the map screen that allows for different characters to be 
          selected based on pushing left or right, but its far from being perfected.
02/01/09- An attempt is being made to create two-way scrolling in the vertical areas. 
          I've been able to make the areas scroll in both directions for the player 
          but not so properly for the background graphics and item placement.
02/06/09- A huge breakthrough has occured in the task of creating two-way scrolling 
          vertical areas. Pertinent JSRs have been placed at 0x3CAD0, 0x3CAF9, and 
          0x3CB08; a JMP at 0x3CAE7; a change from $68 to $65 at 0x3CFE0; and a change 
          of 01 to 02 The bg 0x386F3 and 0x3870F. The bg graphics scroll perfectly 
          when the room is entered from the top and near perfect when from the bottom. 
          A lot of the changes involve ram addresses $59-5C, $65, and $68. It's a 
          very massive relief to get this part of the problem out of the way because 
          for a long, long time it seemed like it would have been nearly impossible 
          to achieve.
02/07/09- Graphical glitch that occured when the player enters from the bottom in the 
          new two-way VSA circumvented. Pertinent JSR (20DACA) at 0x3BBCF.
02/27/09- First draft of 6th musical theme is sequenced.
03/05/09- 7th theme "Opus 13" of Rondo of Blood sequenced for the Armory stage.
03/19/09- Minor breakthrough on the preservation of items/enemies in VSAs. I changed 
          the direction of a very pertinent branch at 0x13967 to make the candles 
          reappear. Also, a nullification of 5 bytes at 0x28416 apparently preserves 
          some enemies in a similar way to the candles. However, both of these attempts 
          at preservation are riddled with a few glitches.
03/31/09- Minor tweak at 0x13783, in an attempt to preserve other enemies in the VSA. 
          Also, some progress on the map screen itself. The ability to draw graphic 
          tiles on the screen provides for a very possible method of incorporating 
          a real time map. The graphics for the screen itself have been redrawn. The 
          player has an indicator for when the player is selected.
04/01/09- More on the map screen was developed. Palettes were decoded and the threshold 
          for graphics to appear on the screen was expanded (0x2087). The player can now 
          only select a character after the character has been found in the game first, 
          and the characters can be appropriately toggeled through on the menu screen.
          $03FF is currently used to indicate the characters that the player can use.
04/02/09- Text of character names now appear on the select screen. Some glitch graphics 
          were properly eliminated on that screen as well.
04/03/09- An arrow icon to toggle through characters was added to select/map screen; It 
          is the game's first true custom sprite and it should be noted that I haven't 
          yet decoded how sprites are loaded from tables yet so the area in the chr rom 
          it is drawn should ideally be from the same graphics of that of the map screen.
04/05/09- Unsuccessful attempt to get the characters' graphics to display correctly 
          one the map screen has been exited. However, a routine has been created at 
          0x3FA63 to designate more calculatory space for the map screen routine in the 
          98 bank of rom.
04/06/09- Elusive ram address that determines proper graphical animation for each of the 
          characters has been identified ($48C) and used in a routine at 0x33CED to 
          properly adjust the characters' graphics once the player has selected a 
          certain character. Weapons of characters are preserved using ram addresses 
          $3FD and $3FE and a JSR at 0x2E17D. Annoying graphical glitches involving ram 
          $780-7C2 persist once the map screen is exited; this whole block of ram needs 
          to be freed up for real time mapping.
04/07/09- Extra digit in the money counter in the HUD eliminated by a JMP at 0x3E919. 
          I also redefined the ram address that controls the room changes from $46E to 
          $3FC because it was causing a palette glitch with some of the items. And while 
          did that, I noticed some fairly amateur programming from when I first started 
          this project way back in Jan 08. Cured a slight graphical glitch at 0xD97 
          involving the weapon display in the HUD. A glitch involving the return from 
          the map screen in which the screen would scroll while the screen was locked 
          was bypassed at 0x38680 and some surrounding branches were altered accordingly. 
          This glitch fix seems to have the potential for further glitches because of its 
          sloppy and precarious nature.
04/11/09- X, Y coordiantes for player position in the castle now increase and decrease as 
          the player moves about the castle entirely; X changes as the player moves 
          across an SSA (JSR at 0x3D362); Y changes as the player moves up and down VSA 
          (JSRs at 0x3CA7D and 0x3CABC) and as they go up and down staircases to different 
          rooms (JSR at 0x3F61D). $2D is once again used as a temporary storage device. 
          A minor error in coding is detected when the player restarts from a "game over" 
          involving the accidental newly preserved $3FC.
04/12/09- Nullified 5 bytes at 0x2086 to free up address $783 for the map screen.
04/13/09- Ram address $38, formerly used to keep track of the upper most digits of score, 
          has now been assigned to assist in keeping track of the player's current 
          location in each stage of the castle. Some parameters and lines of code were 
          altered in a small area of rom starting at 0xBF7 to no longer have $38 help 
          keep track of score, no longer give extra lives to the player due to score, 
          and to set the player's money to a maximum value of 999. The routine for the 
          definition of $38 is at 0x3DDD7.
04/14/09- Ram addresses $78A-7C2 have been freed up for real time mapping. Palettes are 
          now loaded form the same tables as the ones used in each stage of the castle. 
          A new JSR is replaced at 0x531 to make this possible. More rom is freed up in 
          the 0x2000-2200 region. 5 bytes at 0x2086 restored to original state as a 
          glitch was detected. $1C loaded at 0x13FE5 to blackout some glitch graphics 
          that occured when transitioning to the map screen.
04/15/09- Changed the ram for the sprite preservation routine from $780-79B to $3E4-3FB. 
          Only x17 sprites are preserved instead of x1B. The remaining sprites are now 
          preserved (such as weapons in use) after nullifying a routine at 0x3F591. Also 
          killed a likely useless routine that looked to be an attempt to restore the 
          VSAs after a map screen exit at 0x3DD50 and ram $3F0-3F5 have been freed (only 
          to be used in the sprite preservation routine). Killed a routine that wiped 
          $780-7C2 at 0x1183. Many smaller scale wipes are used like this in the game 
          and occasionally this set of ram is used for special cases. A glitch where the 
          the graphics of the players attack would not display properly was fixed with a 
          JMP at 0x3E7FB. Void left by the once existed $780 wipe routine at 0x1184 now 
          is a routine that fixes a glitch that preserved $413 (player attack graphics) 
          on accident when entering a new area.
04/16/09- Travel progress of the player is now kept track via ram addresses $790-7C1, 
          and based on the status of $32 (or $A6, if $32=0C) and $38. This event should 
          eventually lead up to appropriate map tiles drawn on the map screen showing 
          the rooms in the castle that player has traveled through.
04/22/09- Map tiles representing the path of the players travel now appear on the map 
          screen, which means that real time mapping now exists. However, this is at the 
          expense of a vast amount of memory, both ROM and RAM. RAM addresses $790-7C1 
          still have several objects that are dependent on them that will have to be 
          tediously reconfigured (the hidden items in the walls is one notable example). 
          The proof is there, but the tile drawing routine itself is very unclean at 
          the moment and will need to be amended to perfection. The method to draw the 
          tiles from $790-7C1 begins at 0x33693, and is called by a JSR near the end 
          of the map screen initiation routine.
04/24/09- The map tiles now are represented correctly on the map after a few adjustments 
          in the big tile drawing routine, specifically from 0x336B8-F.
04/27/09- The sprite representing the current location of the player in the stage on the 
          map screen was added to a routine starting at 0x202E.
04/28/09- A cause of the wipe of page $300 of RAM (data that stores tiles for bg-gfx) 
          has been identified: simply increment $6B. This should allow as many items 
          to be drawn on the map screen. A distinct set of bg palettes are now loaded 
          on the map screen with some code at 0x22C4.
04/29/09- An important feature was added to the map screen: the whole map of an area 
          is displayed in the event that the player collects a "map item" for that area. 
          Map tiles representing unexplored parts of the area are dark, explored parts 
          are a brighter color. "Boss gone" address changed from $46F to $3BF and the 
          temporary storage for it has been changed from $2D to $86.
05/02/09- Made an attempt to attach parts areas to other areas... in other words, I 
          took a piece of "level 3" and made it part of "level 1" in order to add 
          more rooms to the Entrance area. I've devised a systematic method for editing 
          the games levels without the aid of reVamp, which can no longer support the 
          game because of some pointers that I altered that were pertinent to TSA data. 
          I still, however, have been using reVamp as visual aid to help me edit the 
          game.
05/04/09- A ton of reconfiguration regarding the room changes was done to support 5 
          different exits from a stage block rather than 3. Coding at 0x33EXX, 
          0x3F9XX parts of rom and the tables at 133XX were altered durastically. Ram 
          addresses $3BD and $3BE are used as storage of the status of $7E an $7F when 
          the player enters the room, but they don't do anything at this point. The 
          player can leave a block at two different locations at the left now, as well 
          as two different ones at the right, but there's a slight limitation in which 
          if there are two for one side one of them has to be in the bottom most room, 
          which shouldn't be too much of a limit factor when it comes to level design.
05/05/09- Eliminated a section of code that forced the plyer to start a specific location 
          once they "game overed" at 0xF9A. The x18 sprite preservation has been moved 
          from $3E4-3FB to the $3A0-3BF region in order to preserve permanent RAM; the 
          cost of this however is to increase $6B DURING the map tile drawing routines 
          in order to reuse $300 RAM before it overwrites sprite preservation RAM. The 
          "boss gone" byte was once again moved to a safer location, $3FB. $3BD, $3BE 
          were moved to $3F9, $3FA and are properly implemented to retain the player's 
          map position after they restart after losing a life.
05/14/09- Music track 8 completed after several days. An epic folk rhapsody likely for 
          the Alchemy Lab.
05/17/09- The default Y coordinate of the player position sprite on the map screen was 
          altered for practical reasons; values for this were changed at 0x2034, 
          0x3DE60, and the table at 0x3DE90. Official level design begun.
05/22/09- Touching up on the initial layout for Entrance, mostly just getting accustomed 
          to making levels in the game. It is mere busy work, very tedious/tiring, but 
          I'd rather do it this way than try to redesign the editor.
05/28/09- Layout for the Alchemy Lab completed.
05/29/09- Attempted to write in the map for the Alchemy Lab, and many glitches occured. 
          Annoyingly, I had to reconfigure some of the map tile drawing routine, which 
          only seemed to be designed to only work for the game's first stage. The map 
          writing engine itself had some ammendments, in which the tiles in horizontal 
          rooms no longer are drawn via $57, but rather $59; This not only gets rid of 
          a glitch that upsets the players position on the map when going down certain 
          staircases but also makes the player's position in a room more acurrately 
          portrayed on the map.
08/29/09- Three month hiatus over. Inserted new sprite graphics for a few of the game's 
          enemies. Much of the sprite data has been decoded.
08/31/09- Graphics of most traditional Castlevania enemies now in game. Entrance layout 
          officially complete.
09/02/09- Armory layout construction begins.
09/03/09- A long, long search for the event which causes certain graphical tiles to be 
          solid ground in a tileset has concluded with the finding of a seemingly 
          simplistic attribute table near the top of the rom at 0x43C. Collision on the 
          screen is mapped out at $6E0-76F, and what is determined as collision for 
          these bg tiles is defined at $770-77F. Exactly how they are defined is still 
          unknown, but finding out such would prove to be invaluable. I've already been 
          getting rid of unwanted solid collision in certain tilesets already.
09/16/09- Armory layout completed. I stopped spending too much time on decorating the 
          background and focused more on creating the level's layout. The map for this 
          area and those of all the subsequential areas to be made will be created once 
          their official layouts have been created.
12/27/09- Production on Cadence of Agony is halted permanently. The reason for this shall 
          be described elsewhere.